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ABSTRACT 


This thesis explores the creation of a conceptual design for a database that would 
assist any Naval shore command with its internal information needs. The database is 
intended to be a multi-user database accessed via a local area network (LAN). The thesis 
examines the administration and information needs of the command as an interrelated 
whole rather than as individual division and departments. 

As the Navy changes to meet different world situations, the need for administrative 
and management information within a shore command has increased. Most shore 
commands have attempted to meet this need with single-user relational databases. Often 
these databases are poorly designed and incorrectly implemented. 

This project uses the enhanced entity relationship model to create a conceptual 
design for an administrative database. This basic model can be customized to fit the 
needs of a shore command. Fleet Numerical Oceanography Center, Monterey, CA was 
used to represent a typical mid-sized shore command to develop the basic model and 
prototype. 
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I. INTRODUCTION 


This thesis explores the creation of a conceptual design for a multi-user relational 
database that would serve any Naval shore command with its internal information needs 
via a local area network. The thesis examines the administration and information needs 
of the command as an interrelated whole rather than individual division and departments. 

A. BACKGROUND 

1. Historical Perspective 

The Navy has been using computers and developing applications for many 
years to support its operational mission. There are a variety of computers and software 
used in weapons systems, simulators, accounting and payroll. Traditionally the internal 
administration and management of a command, however, have received very little 
automated data processing (ADP) support. These internal management functions 
consume a large portion of a manager’s time. The officers and senior civil service 
personnel spend valuable hours tracking down such things as purchase requests or 
personnel information. 

When the Navy’s Z-248 micro-computer contract became available, personal 
computers and commercial off-the-shelf software (COTS) began appearing throughout 
shore commands. Managers immediately recognized the potential of word processing on 
microcomputers to relieve the overwhelming paperwork encountered each day. Navy 
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personnel began developing small applications beyond word processing by taking 
advantage of COTS spreadsheets, graphic programs and database management systems 
available from the Z-248 contract. 

2. Hie Problem 

One piece of software that was purchased with the Z-248 PC contract was a 
relational database management software package [Ref. l:pp. 135-148]. Numerous 
databases were developed by personnel who had little or no expertise with database 
design. Examination of these databases shows there is very little design or user 
documentation available. The databases are not normalized [Ref. l:p.373]. Many users 
feel the applications are awkward to use and inaccurate. Often, only the developer of 
the database can actually use the application. While information may be lost each time 
a personnel turnover occurs, these databases fill an immediate need for more effective 
control of information within the command. 

Personnel in the command find these databases frustrating. The databases are 
rarely accurate and require too much effort to maintain. Check-in/check-out procedures 
illustrate the number of duplicate databa%s maintained within the command. When new 
sailors report to the command, they are given a check-in sheet with 10 to 15 different 
individuals or divisions they must visit. At each location the sailor repeats personal data. 
For example, names, social security numbers and home phone numbers might be retained 
by the administration officer, the department head, the division officer, the security 
officer, the master chief petty officer of the command and the command duty officer. 
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At most of these sites a database residing on a personal computer is u^>ed to record tiw 
sailor’s arrival. 

Upon the sailor’s departure the process is reversed, except now each person 
on the check-out sheet attempts to determine if the individual has any outstanding acticm 
items requiring clearance before the sailor’s departure. Have they returned all 
government property? Have they turned in their access badges? Each division then 
modifies their database to record the individual’s departure. 

These processes make check-in and check-out one of the most dreaded aspects 
of a transfer. Because check-in and check-out are so frustrating, individuals often 
attempt to circumvent the process. A sailor visits only those sites deemed in their best 
interest to notify of their arrival or departure. It is not unusual for different divisions in 
a command to have widely different databases concerning the personnel assigned to the 
command. 

A sophisticated command recognizes the problem of unsychronized databases 
and creates elaborate administrative procedures to ensure the critical databases are kept 
synchronized. Data may be transferred by paper report or on floppy disk between the 
divisions. While this eliminates the problem of unsynchronized data, the data is usually 
late and the intricate administrative procedures are too complex to be performed 
correctly. 

We propose that one multi-user database be maintained at a command and 
each of the various departments and divisions have access to the information they need. 
This was impossible a few years ago since most shore commands did not have any type 
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of computer network accessible by different people in different locations. If a command 
had a multi-user computer network it’s primary purpose was certainly not for the 
administration and management of the command. Now, the availability of personal 
computers, LAN technology and inexpensive multi-user relational database software 
make this proposal feasible. 

3. Local Area Networks 

Local area networks combine the benefits of a personal computer with those 
of a multi-user system. A LAN allows users to communicate with one another and 
access a multi-user database. Data can be transferred to an individual’s personal 
computer for further manipulation. A LAN also allows expensive hardware and software 
to be shared among many users. 

As LAN technology became less expensive it became more commonplace. 
Many large and mid-sized Naval shore commands have invested in LANs, originally to 
share expensive resources; they are now beginning to see the benefits of using the LAN 
to quickly develop shared relational databases. There are many inexpensive COTS 
database management packages on the market to help managers build relational databases 
which meet their requirements. 

B. RESEARCH QUESTIONS 

The purpose of this su dy is to answer three research questions concerning the 
design and implementation of a Naval shore command administrative and managemmt 
relational database; 
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• Which management functions of a Naval shore command are suited for 
implementation in a multi-user, relational database? 

• Can a generic, conceptual database model be designed to meet the needs of any 
Naval shore command? 

• What are the potential benefits of implementing such a database? 

C. METHODOLOGY 

The Fleet Numerical Oceanography Center (FLENUMOCEANCEN) in Monterey, 
CA volunteered to serve as a test-bed for this research. FLENUMOCEANCEN is a 
command of approximately 350 military and civil service employees. There are also a 
number of contractors that work at FLENUMOCEANCEN facilities. 
FLENUMOCEANCEN has a traditional chain of command structure with a commanding 
officer (CO), an executive officer (XO), department heads and division officers. 

Information for this thesis was collected by interviewing all department heads, 
many division officers, and personnel currently responsible for maintaining or updating 
the command’s existing databases. Existing databases were examined to determine the 
merits and demerits of the data maintained. No attempt was made to convert the 
application code of their systems. 

Chapter II examines the data and functional requirements of this project. Chapter 
III contains a brief discussion of the conceptual design model used for this project and 
Chapter IV discusses the model developed during this project. Chapter V considers some 
security and administrative requirements for implementation of a database. Chapter VI 
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reviews the prototype database developed for FLENUMOCEANCEN and Chapter VII 
concludes this thesis. 
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II. DATA REQUIREMENTS 


This chapter discusses the administrative information needs at 
FLENUMOCEANCEN. Interviews and existing single-user database systems were used 
to help categorize the information needs. The personnel also discussed their concerns 
regarding the implementation of a multi-user database. 

A. INFORMATION NEEDS 
1. The Managers 

The managers at FLENUMOCEANCEN had two distinct requirements for 
their command information management system. First, they had a list of routine items 
on which they wanted up-to-the-minute information. These items centered on budget 
status and equipment accountability (plant property). The managers were easily able to 
describe these information requirements. 

The second requirement was the need for information to meet future 
management changes. The Navy is changing drastically and rapidly and it is difficult to 
anticipate what that information would be. The biggest area of change is the budget 
process within with the Department of Defense’s (DOD) current financial management 
system. The budget process procures money for the Department of Defense from 
Congress, and determines a command’s fiscal processes and policies. If the budget 
process is changed, a new set of procedures is required. 
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Not knowing the future, most managers agree they need a database containing 
information concerning the daily operations of FLENUMOCEANCEN and the work 
output production. This data will be manipulated as required to develop information 
concerning the real costs of operating FLENUMOCEANCEN and producing work 
outputs. The managers desired an easy-to-leam ad hoc query language such as 
Structured Query Language (SQL) [Ref. l:pp. 175-205]. Many managers are already 
familiar with the capabilities of SQL and feel a brief training course is all they need to 
become productive. 

2. The Employees 

The needs of the employees are different from the managers. They want help 
coping with their daily tasks. There was much discussion concerning the possibility of 
eliminating the paperwork flow between departments and divisions. Where paperwork 
could not be eliminated, they want assistance filling out the forms. The employees want 
reference information on-line allowing copies of reports and instructions to be discarded. 

The employees also feel they can benefit from the flexibility of SQL. While 
they do not envision using SQL frequently for the performance of daily tasks, they felt 
managers should retrieve information themselves, thereby freeing the employees from 
some time-consuming research tasks. 

The third requirement of the employees is the most critical. The database and 
applications have to provide positive feedback. Several existing database systems do not 
provide any feedback-transactions are entered into the database and disappear. 
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Employees maintain two set of records, one on the computer and a second in a log book. 
Any developed system must be accepted by the employees as efficient. 


B. THE INTERVIEWS 

After the first few interviews, it was obvious the personnel at 
FLENUMOCEANCEN had varying degrees of knowledge of computer systems in 
general and databases in particular. A brief tutorial was prepared to help educate these 
personnel. The tutorial contained an example of a check-in process and a description of 
the data modeling process. Entity relationship diagrams and relational schema diagrams 
were explained. The tutorial was distributed to personnel before their interview. 

Some personnel required more than one interview. The first interview was spent 
reviewing the tutorial and generating some starting points. The succeeding interviews 
were used to gather ideas and requirements for this project. 

FLENUMOCEANCEN personnel were excited by the idea of sharing information 
between divisions. The best ideas concerning a department frequently came from outside 
the department. Department personnel were surprised to discover their contemporaries 
felt their department was providing untimely information. 

There was also concern about the ability of appropriate security procedures 
protecting privacy act and sensitive data. These concerns determined if an administrative 
or management function would be included in the database. 
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C. EXISTING DATABASES 

Many areas considered for this project have some form of single user database 
already in operation. The most popular is personnel, accounting and plant property 
databases. Several other databases are maintained in spreadsheets and word processors. 

FLENUMOCEANCEN established standardized COTS packages for employee use. 
The administrative databases use dBASE‘ IV software. Lotus 1-2-3^ is the spreadsheet 
software and Wordstar^ is used for word processing. FLENUMOCEANCEN recently 
implemented a LAN and a calendar package containing information concerning 
employees’ daily schedules. Typical of most shore commands, FLENUMOCEANCEN 
is experiencing problems with the current systems. The databases were developed by 
individuals who had little formal or practical training in database design. Often, the 
original programmer had transferred and current personnel are "stuck" with a system 
which only partially meets their needs. None of the databases are designed to be shared 
on a LAN. 

The focus in these early databases was on the application rather than on the data. 
Some of these relational databases do not meet the requirement of the first normal form 
[Ref. l:p. 373], which is the minimum format required to categorize a database as 
relational. Many older systems began as dBASE II databases and were "patched up" as 
each succeeding version of dBASE was released. 

‘dBASE is a registered trademark of Borland International, Inc. 

^Lotus 1-2-3 is a registered trademark of Lotus Development Corporation. 

^Wordstar is a registered trademark of Wordstar International. 
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While there are many problems with the existing databases, it is important to note 
these databases met an important need when developed. They provided information to 
someone who needed it. In the short-run they were very useful. 

D. FUNCTIONAL AREAS 

Almost every administrative and operational function is proposed for inclusion in 
the database. Two criteria are established to control the scope of the database. First, 
the data has to be something of interest to more than one department. Second, the data 
must have a sponsor-someone willing to maintain the data. The first criteria is 
occasionally relaxed when collecting data required for a replacement financial 
management system. 

The following areas are included in the database design: 

• Personnel: employees, training, visitors, awards, security access, work schedules, 
employee qualifications, employee specialties/resources 

• General administration: correspondence, logs, instructions, plans of the week, 
plans of action 

• Property and facilities: major property, minor property, other property (manuals, 
tapes, etc.), buildings, work requests 

• Financial management: contractors, customers, products, budgets, supplies, 
inventories 

These functions are chosen for their concern to most shore commands with the 
possible exception of the contractor area. The data in these areas are of interest to more 
than one department and currently being maintained by someone in the command. 
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Several areas are not included. The first area is categorized as not of general 
interest in the command. The second area contains personnel data such as punitive 
records. This information is considered too sensitive to contain in this type of COTS, 
multi-user database. 

An additional concern is the legal requirement to obtain a signature on documents. 
Any document requiring a signature can be augmented with the database, but not 
replaced. For example, FLENUMOCEANCEN uses a locally designed work sheet to 
begin processing travel orders. This work sheet could be eliminated and replaced with 
a travel application in the database. The database could then prepare the actual travel 
orders requiring appropriate signature for completion. 
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in. THE DESIGN AND IMPLEMENTATION MODELS 


This chapter briefly discusses the advantages of the enhanced entity relationship 
(EER) model as a database design model and gives steps necessary to convert the EER 
model to the relational model for implementation. 

A. THE ENHANCED ENTITY RELATIONSHIP MODEL 

The enhanced entity relationship model [Ref l:p. 410] was chosen as the design 
model. The EER model is a high-level conceptual data model. This model allows a 
great deal of information to be displayed in an enhanced entity relationship diagram 
(EERD). These diagrams can be used by the database designer and the users to diagram 
the mini-world being considered. The EER model is not an implementation model. 
There are no commercial database products available which implement the EER model 
directly [Ref. l:p. 37], 

To illustrate the flexibility of the EER model and diagram, consider figure 1, a 
mini-world where shore commands may hire employees. Employees must work for some 
shore command, but only one. Each employee must be assigned a billet. The employees 
must be either civil service employees or military employees. The shore command has 
a name, a unit identification code (UIC) and a commanding officer. Each UIC and 
commanding officer is unique. Each employee has a last name, a unique social security 
number (SSN) and one or more office phone numbers. Civil service employees have a 
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Figure 1. HER Diagrams: An Example 


civil service series number and a grade/step. Military members have a rank and a 
planned rotation date (PRD). A billet has a unique billet sequence code (BSC) and a 
title. Each employee may have several family members. The family member has a first 
name, a date of birth (DOB) and a ^x. Each employee is supervised by another 
employee. Employees may attend training courses. Each course is attended by several 
employees. Courses have an identification code and a cost. 
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Figure 2 contains the symbols used in HER diagram construction [Ref. l:pp. 57, 
412]. While the EBRD may be intuitive to most users, the following definitions may be 
helpful to correctly interpret the EBRD: 


• Entity type: a group of things in the real world with an independent existence [Ref 
1: p. 40]. Examples of entities are COMMAND and EMPLOYEE. Entity types 
are represented by rectangles. 

• Weak Entity Type: an entity type without a key attribute of its own [Ref. 1: p. 
52]. The FAMILY MEMBER entity type is a weak entity type in figure 1. Weak 
entity types are represented by double rectangles. The weak entity type only has 
a partial key, the primary key of the owner entity type is also needed. The partial 
key is represented by a dashed underscore. 

• Attribute: "a property of the entity describing the entity" [Ref 1: p. 40]. 
Examples of simple attributes for the EMPLOYEE entity are last name, social 
security number and office phone number. A key attribute is an attribute or a 
group of attributes uniquely identifying each entity. Attributes are represented by 
ovals. Key attributes are represented by a solid underscore. Partial keys are 
represented by a dashed underscore. 

• Multi-Valued Attribute: an attribute having multiple values for a single entity [Ref 
1 :p. 41]. The attribute office phone number might be multi-valued if there is more 
than one number available to an office. Multi-valued attributes are represented by 
double ovals. 

• Relationship type: "a set of associations among entities" [Ref l:p. 46]. A 
command employs employees. The COMMAND entity is related to the 
EMPLOYEE entity through the employs relationship. Relationship types are 
usually described with verbs. Relationship types are represented by diamonds. 

• Identifying Relationship: a relationship type used to link a weak entity type to its 
owner [Ref. l:p. 52] The has family relationship type is an identifying 
relationship in figure 1. Identifying relationships-types are represented by double 
diamonds. 

• Recursive Relationship: a relationship where an entity type participates in a 
relationship more than once in different roles [Ref. l:p. 49] The supervision 
relationship is recursive. An employee is supervised by another employee. A 
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recursive relationship type can be recognized by the "circle” from the entity type 
to the relationship type back to the original entity type. 

• ISA Relationship: a special relationship for creating subclasses of entities [Ref l:p. 
410]. The EMPLOYEE entity type is the superclass. Each employee is either a 
civil service employee or a military employee. CIVIL SERVICE and MILITARY 
are subclasses. An ISA relationship type is represented by a triangle. 

• Participation Constraint: "the existence of an entity depends on its being related 
to another entity via the relationship type" [Ref. l:p. 50]. In figure 1, 
EMPLOYEE participates totally in the employs relationship. Every employee must 
be employed by a command. The COMMAND entity only participates partially 
in the relationship. Each command may not employ employees. Partial 
participation is represented by a single line between the entity type and the 
relationship type; total participation is represented by a double line. 

• Cardinality Ratio: "the number of relationship instances that an entity can 
participate in" [Ref. l:p. 50]. The three types are one-to-one (1:1), one-to-many 
(1:N) and many-to-many (M:N). In figure 1, the COMMAND:EMPLOYEE 
relationship is an example of a 1 :N relationship. One command may employ many 
employees. An example of a 1:1 relationship is EMPLOYEE:BILLET. One 
employee is assigned to one billet. COURSE:EMPLOYEE is an example of a 
M:N relationship. A course is taken by many employees and employees take many 
courses. 


j Entity Type 


Weak Entity Type 
Relationship Type 



Identifying 
Relationship Type 



Attribute 

Multi-Valued 

Attribute 

Primary Key 
Partial Key 


Partial 

Participation 

Total 

Participation 



IS_A 

Relationship Type 



Cardinality Ratio 
1 to Many 


Figure 2. EER Diagram Notation 
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B. THE RELATIONAL MODEL 


Since the EER model is not currently available as a COTS product, it is necessary 
to translate or map the EER model to an implementation model. The relational model 
was chosen for this project because of its flexibility, availability and cost. One of the 
benefits of the EER model is that it can be mapped quickly and easily to the relational 
model. Figures 3 and 4 illustrate the mapping process. There are eight steps to the 
mapping process [Ref. l:pp. 329-331, 427-428]: 


• Step 1: For each regular entity type, create a relation containing all the simple 
attributes of the entity type. Assign a unique attribute or unique group of attributes 
as the primary key. Underscore the primary key. Identify any other attributes 
which could serve as candidate keys (c.k.). Figure 3, step 1 shows four relations, 
COMMAND, EMPLOYEE, BILLET and COURSE that were created. 

• Step 2: For each weak entity type, create a relation containing all the simple 
attributes of the entity type. Also include as a foreign key (f.k.), the key 
attribute(s) of the owner entity type. Figure 3, step 2 shows the addition of the 
FAMILY MEMBER relation with the inclusion of the SSN attribute from the 
EMPLOY"eE relation. 

• Step 3: For each binary 1:1 relationship, identify the two relationships involved 
and add the primary key of one relation as a foreign key in the other. Figure 3, 
step 3 shows that the SSN attribute from EMPLOYEE was included in the BILLET 
relation. 

• Step 4; For each non-weak binary 1:N relationship, identify the relationship on the 
1 side and include its primary key as a foreign key in the relationship on the N 
side. Figure 3, step 4 shows the UIC attribute from the COMMAND relationship 
included in the EMPLOYEE relation. Since the supervision relationship is 
recursive, the EMPLOYEE relation also includes a new attribute called Boss_SSN 
which represents the supervisor’s SSN as a foreign key which refers back to the 
SSN in the same EMPLOYEE relation. 

• Step 5: For each binary M:N relationship, create a new relation and include the 
primary keys from both of the relations in the new relation. Also include any 
attributes of the relationship in the new relation. In figure 3, step 5 the new 


17 



18 













































































relation EMP-COURSE is created. It’s primary key is the combination of the SSN 
and CID attributes from the EMPLOYEE and COURSE relations. The attribute 
Date was added to the new relation. 

• Step 6: For each multi-valued attribute, create a new relation including the 
primary key of the entity and the multi-valued attribute. In figure 4, step 6 a new 
relation EMP-PHONE was created with the attributes Office_Phone and SSN. The 
primary key for the EMP-PHONE relation is a combination of both attributes. 

• Step 7; For each n-ary relationship, create a new relationship and include as 
foreign keys the primary keys of each relation in the n-ary relationship. This step 
is not necessary in this example because this mini-world does not contain a 
relationship with more than two entity types participating, 

• Step 8: For each subclass ISA entity, create a relation and include as the foreign 
and primary key, the primary key of the superclass encity type. In figure 4, step 
8 the CIVIL SERVICE and MILITARY relations were created. 


Elmasri and Navathe [Ref. l:pp. 427-428] propose several different options for 
completing step 8. The method used in step 8 of this example provides relations that 
duplicate only the primary key in the relations representing the subclass entity types. 
The other options duplicate more than just the primary key or result in relations having 
many empty attributes. This option is appropriate for this type of superclass/subclass 
relationship type [Ref. l:p. 428]. 

Upon completion of these eight steps, the relations are in the 1st normal form 
(INF) of the relational model [Ref l:p. 373], Normalization is "The process of 
determining the correct location and function for each attribute in order to correctly 
formulate the relational schema." [Ref 2;p. 56] While eight norma! forms are defined 
for the relational model, it is not always necessary or desirable to normalize to the 
highest possible form [Ref l:pp. 372]. The higher normal forms are difficult to 
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understand and divide the database into many small relations causing serious performance 
problems. The fourth level, Boyce-Codd Normal Form (BCNF) is considered a good 
compromise [Ref. l:p. 372]. The example in step 8 of figure 3 also happens to be in 
BCNF, without any additional work. 
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IV. THE BASIC MODEL 


This chapter presents the EER model created during this project. The chapter 
outlines the refinement process and discusses methods to modify the model for 
implementation at different commands. 

A. THE CONCEPTUAL SCHEMA DESIGN PROCESS 

After the interviews and review of the existing systems, an initial EER model was 
created. The model underwent a refining process resulting in the model contained in 
Appendix A. When looking at the command as a whole, it became obvious that entity 
types, considered unique by division personnel, were in fact minor variations of one 
entity type. For example, the office supplies, the PC software supplies and the spare 
parts inventory were all condensed into the INVENTORY entity type. This first major 
refinement involved consolidating these separate entity types into broader entity types. 
This process cut the number of entity types by approximately 30 percent. 

At this point, the model had three main focal points. The EMPLOYEE, 
ORGANIZATION and BUDGET entity types were hubs around which the other entity 
types were arrayed. A fourth area, general administration, did not have a hub but was 
a recognizable group about the ORGANIZATION entity type. 

After the initial refinement, the model was reviewed by FLENUMOCEANCEN 
representatives and officers that had served at different types of Naval shore commands. 
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It became obvious that the model did not adequately represent commands other than 
FLENUMOCEANCEN. To make the model functional for other commands, it was 
necessary to remove many of the relationship types between the entity types. For 
example, at some commands an employee may not attend a training course unless the 
course is listed on the employee’s individual development plan (IDP). This would create 
a ternary relationship between EMPLOYEE, COURSE and INDIVIDUAL 
DEVELOPMENT PLAN. At other commands, the IDP is only a guiding document and 
is not meant to restrict an employee’s course selection. 

This second refinement reduced the number of relationship types by 40 percent. 
The resulting model lost its BUDGET hub and was converted to a broad area concerning 
the fiscal management activities of a command. The ORGANIZATION and 
EMPLOYEE hubs remained. 

B. THE BASIC MODEL 

The refinement process created a model minimally acceptable to all the 
representatives but insufficient to meet any one representative’s needs. The fiscal area 
created the most dissension among the officers. The financial management of a 
command is guided by many regulations but each command has implemented varying 
procedures and policies for complying with these regulations. For example, the 
PHONE CALL entity type represents the long-distance phone calls made by the 
organization’s employees. These calls must be accounted for upon receipt of the phone 
bill. At some commands each phone call is considered an expenditure against the 


department’s budget, thereby creating a relationship between PHONE CALL and 
EXPENDITURE. However, at large commands, the phone calls are certified by the 
department, but are paid out of a central account whose budget is not retained at the 
lower level. 

The differences in procedures could usually be traced to the size of the command. 
The large shore commands have a high percentage of civilian personnel and non- 
traditional chain of command structures. At these commands, the loosest form of the 
model is necessary. At the smaller commands with a traditional chain of command 
structure, a tighter model may be implemented. None of the representatives agree upon 
the different attributes which should be associated with each entity type. 

The basic model is diagrammed in figures 6 through 7 in Appendix A. The model 
is divided into four sections following the four general functional areas: 

• Section 1: Personnel 

• Section 2: Facilities and property 

• Section 3; Financial management 

• Section 4; General administration 

Appendix B is a data dictionary containing an alphabetical list of the entity types and a 
brief description of the entity types. 
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C. CUSTOMIZING THE MODEL 


The basic model may be mapped to the relational model for implementation. The 
basic model is very "loose" and represents those commands having a non-traditional 
chain of command structure. The traditional responsibilities of the commanding officer 
in this type of command are delegated to several individuals due to the size of the 
command. This structure is typical of the large commands in Washington, Norfolk, San 
Diego, Pearl Harbor, etc. The divisions in these commands may contain several hundred 
people and are usually divided into smaller units for daily operations. These very large 
commands require the most flexible model for their database. The database is most 
useful at the smaller working group level. 

A medium-sized command with a traditional chain of command structure would 
benefit from a "tighter" version of the basic model. This command could modify the 
model to include more relationship types between the entity types such as the phone bill 
example above. Personalizing the model allows the command to accurately represent 
their particular situation. 

Customizing the basic model involves four steps. First, examine the entity types 
and relationship types in the basic model. Do they generally match the procedures at 
your command? Make any changes as appropriate. Second, begin adding attributes to 
the entities. This may not be straightforward. For example, where would an office 
phone number attribute belong? Some commands have one phone number for each 
division and the attribute should belong to the ORGANIZATION entity type. Some 
commands have single-line phones in each office. In this case, the phone number 
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attribute would belong to the FACILITY entity type. At other commands, the phone 
number is stored in the phone itself. As personnel move from office-to-office they take 
their phone and phone number with them. The EMPLOYEE entity type should be used 
in this situation. 

After the attributes are added, the third step is to review the model. Check each 
entity type and relationship type to ensure they accurately represent your situation. 
Fourth, add any additional relationship types to "tighten" the model. Consider the new 
relationship types carefully, for there is a trade-off. Additional relationship types may 
result in additional relations which will increase the complexity of the database and may 
decrease performance [Ref. l:p. 372]. 
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V. DATABASE ADMINISTRATION AND SECURITY CONSIDERATIONS 


Chapter V discusses some of the policy and operational considerations that must 
be thought about before a multi-user database is implemented. 

A. DATABASE ADMINISTRATOR FUNCTIONS 

While this database is not exceptionally large, it will be used by personnel with 
varying degrees of database expertise. Once the database is complete it will be necessary 
for an individual or group to have database administrator (DBA) responsibilities. These 
responsibilities concern the smooth daily operation of the database. The DBA will be 
responsible for making backup copies of the database, granting access to the database and 
generally monitoring the database for problems. 

The individual assigned the DBA responsibilities should be knowledgeable about 
database practices and procedures in general and with the capabilities of the relational 
database management system (RDBMS) used to implement the database. The DBA 
should interact easily with users from different departments and different levels in the 
chain of command. The DBA’s position in the chain of command should allow the 
impartial pjerformance of their duties. 

The DBA responsibilities for this database should not require full-time porsonnel. 
The exact amount of time spont daily on the DBA functions will depond upon several 
variables. Initially, the procedures used to convert the old single-user databases to the 
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new database will have a dramatic affect on the time required to monitor the database. 
Old single-user applications "patched up" to function in the new system will require a 
great deal of DBA attention. Clean applications written by experienced personnel will 
require less intervention by the DBA. 

The individual’s database experience also will greatly affect the time needed to 
administrate the database, e.g., a knowledgeable individual might require only two hours 
a day to perform the DBA functions while a less experienced person may require four 
or more hours. 

B. DATABASE SECURITY 

The security of the database is one topic that all the interviewees could agree upon. 
The personnel data contained in the database is subject to privacy act restrictions and the 
financial management data is sensitive. Much of the data could be made available for 
general viewing by employees, but modification and deletion of the data is restricted. 

The security features of the database depend primarily upon the RDBMS package. 
COTS packages vary widely in capabilities. Access to data can be controlled through 
the multi-level applications development, but will not affect the individuals who have 
access to the data manipulation language, such as SQL. 

First, the RDBMS should have a user identification and password system. The 
Department of Defense and the Department of the Navy (DON) have extensive and 
explicit requirements for password systems [Ref. 3]. These regulations are usually 
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supplemented by local command policy. The RDBMS should support all levels of 
regulations and policies. 

Second, the RDBMS security system should allow the DBA to restrict access to the 
database by table, column and row. The restrictions should include insert, modify, 
delete and view functions. For example, all users should have view access to the plan 
of the week. Only certain users might be allowed to insert new budget items while other 
users may be allowed to modify the cost attribute for the item. The combinations of 
access to the various entities are large and require the command to make some policy 
decisions. 

Third, the database should have a mechanism for back-tracking transactions and 
"rolling back" the database in case of problems [Ref. l:p. 542]. Each transaction must 
be traced to a specific user. 

Fourth, the database files should be protected. If a user can access the files from 
the operating system, the first three security procedures are useless. Many COTS 
RDBMS packages store the database in easy-to-access ASCII format. 

Another area for consideration is the relationship between the RDBMS security and 
the network security. Perhaps the network can pass user identifications and passwords 
to the DBMS. This may supplement the existing system by providing another layer of 
security. 
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VI. PROTOTYPE 


Chapter VI provides an overview of the single-user prototype developed as part of 
this project. Positive and negative aspects of the database management system software 
are discussed. 

A. THE DATABASE MANAGEMENT SYSTEM 

R.BASE 3.1C'‘ from Microrim was used to implement the prototype. R:BASE 
3.1C was chosen because it meets the American National Standards Institute (ANSI) 
Level 2 SQL standard [Ref. 4;p. 321]. It is readily available on the commercial market, 
though it is not as widely known as some other RDBMS packages. RrBASE can be 
implemented for multiple users on a LAN but the prototype was developed only for a 
single-user. 

RrBASE 3.1C also contains several features that make it an excellent choice for this 
prototype. It contains a data dictionary and an extensive set of aggregate functions not 
included in the SQL standard. RrBASE 3.1C has transaction processing and rollback 
features. The screen and report generators are easy to use and sophisticated. 

RrBASE 3.1C uses SQL to create rules regulating data entry in the database [Ref. 
4rpp. 256-260]. These rules are variations of the SQL select command [Ref. Irp. 178]. 
For example, if the database contains a table called STATES of the 50 state abbreviation 

^RrBASE is a registered trademark of Microrim, Inc. 
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codes and a table called CUSTOMER where customer addresses are entered, the 
paraphrased rule would say, "Add the row to CUSTOMER if the customer’s state code 
is in STATES." The flexibility of SQL allows the creation of very complex rules to help 
maintain the integrity of the database. 

B. PROTOTYPE FUNCTIONS 

Appendix C contains an EERD of the prototype. The organization and personnel 
hubs were chosen as the basic starting points for the prototype. Most of the personnel 
and general administration areas that were included in the prototype were chosen because 
they did not currently have any automated support. Their inclusion was needed to help 
those users envision the possibilities of full implementation. The property area was 
included because all the department heads felt it needed immediate attention. 

The developed applications were very basic. The ability to add, edit and delete 
records using an intuitive menu system was the primary function. The reports developed 
included listing of property, personnel recall bills, plans of action and distribution labels 
for incoming correspondence. 

C. ASSIMILATING EXISTING DATA 

Whenever possible, data from existing databases were incorporated into the 
prototype. The existing data was contained in dBASE IV, Lotus 1-2-3 and various word 
processors. Each of these programs could output the data to an ASCII file. If the data 
needed drastic manipulation, it was imported to a word processor, edited and output 
again to an ASCII file. R:BASE does not store the data in separate ASCII files but 
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contains an import feature [Ref. 5:p. 8-25] that allowed the data to be loaded into the 
database. 

D. LESSONS LEARNED 

R:BASE provided an excellent tool for developing the prototype database. The 
database was created in only one hour while the applications required approximately 25 
hours. The screen and report generators were outstanding. The data dictionary was 
useful but limited in the amount of space allowed for descriptions. 

The R-.BASE security system could control access to tables and columns, but not 
to rows. This means if all the departments’ budgets are stored in one table with an 
attribute to identify the department, there is no way to use this attribute to restrict a 
department head from accessing other departments’ budgets unless it is through an 
application program. 

R:BASE can only link a maximum of five tables when creating a view. There was 
a noticeable delay in response time when SQL was used to join more than three tables 
in a query. 

An additional concern was the speed of the RDBMS. R:BASE’s performance was 
unacceptable on a personal computer with an 80286 processor but provided a response 
time of two or three seconds with an 80386 processor. This might not be a concern on 
a multi-user system as it is unlikely that an 80286 processor would be used as a server. 
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VU. CONCLUSIONS 


This project is considered the first step for developing the requirements in a multi¬ 
user relational database at FLENUMOCEANCEN that can be accessed via a LAN. This 
is the first time that the functional management relationships of the command have been 
viewed as a whole and the conceptual schema for a database designed for the command. 
The management functions outlined in section D of Chapter II are of concern to every 
shore command and are suited for implementation in a multi-user, relational database. 
Most commands will have additional functions that should be included, depending upon 
the command’s mission. Almost any functional area can be included in the model. 
Areas containing extremely sensitive personnel data and classified data should not be 
included; or if included, must have the appropriate security system for the type of data 
[Ref. 3]. 

The model developed and displayed in Appendix A could be used by any command 
as a generic model for a database design, but to be truly effective, the model should be 
personalized for the command. Additional relationship types exist at most commands, 
especially in the financial management section of the model. Unfortunately, it is not 
possible to create one database and application system that could be used at all 
commands. The Naval Computer and Telecommunications Area Master Station Lant 
Detachment has created several products under the GENUS name that provide 
administrative functions. These products have mixed support in the shore community. 
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Some commands feel the GENUS products meet their needs while others do not like the 
procedures required by GENUS products. 


Customizing the design may require creating additional entity types and relationship 
types. Attributes must be added to the design in the appropriate location for the 
command. Next the customized EER model is mapped to the relational model and 
normalized. The design is ready to be implemented in the RDBMS. This process will 
require the attention of a database design professional. While both the mapping process 
and the normalization process have step'by-step instructions, there are always occasions 
when a design decision must be made between two or more options. An experienced 
database designer can evaluate the options and choose the most effective one(s). 

The primary benefit of a successful implementation of this project is the decrease 
in time spent on administrative matters and the availability of timely information to 
support quick response requirements. The need to support these requirements can be 
demonstrated by two programs that could dramatically affect a shore commands 
operations and require the Navy to consider the need for a generic relational 
administrative database design tailored to meet functional requirements [Ref. 6]. The 
first is lue unit costing proposal under which a command would be provided a set amount 
of funding for every product it produces. A second proposal is the Defense Business 
Operating Fund (DBOF), which is a program where military commands operate as 
businesses and charge ot. .r commands for products and services. This is currently how 
the Industrial Fund activities, such as ship yards, operate. DBOF is currently being 
tested at several shore commands and might apply to all commands in the next few years. 
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Both of these initiatives will require a command to have access to its real costs and 
outputs. Implementation of DBOF will require sophisticated billing and accounting 
software while unit costing will require certification of outputs. This database design is 
the first step toward preparing for these initiatives. 

The implementation of a multi-user, relational database will require the attention 
of a database administrator to function correctly. Experienced database administrators 
already have many demands placed upon their time. This database will be an additional 
burden. Another cost is the purchase of a sophisticated COTS package to implement the 
design and training of command personnel to use the COTS. 

The basic model developed during this project is intended to provide a starting 
point for shore commands. The model can be used to evaluate COTS management 
information systems for their applicability to meet the Naval shore command’s 
environmental requirements. Products that cannot provide this minimum functionality 
are ineffective and will not meet the needs of the command. A tailored model can be 
used to establish specifications and design requirements for the development a 
command’s management information system. 
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APPENDIX A 


THE BASIC ENHANCED ENTITY RELATIONSHIP MODEL 


This appendix contains the basic enhanced entity relationship model developed 
during this thesis. 
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Figure 6. EBRD Section 2 
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Figure 8. HERD Section 4 
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APPENDIX B 


THE ENTITY TYPE DESCRIPTIONS 

This appendix contains the descriptions of the entity types developed for the model 
in Appendix A. The entity type codes are R for regular, W for weak and S for subclass. 
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Entity Type Name 


HERD Entity 

Section Type Description 


ACCESS 

1 

R 

A type of permission or authorization that 
might be granted to people. For example, 
authorization to drive military vehicles or 
individuals who may have access to a room 
or building. 

ACTIVE ENLISTED 

1 

S 

An EMPLOYEE who is an active duty 
enlisted member. 

ACTIVE OFFICER 

1 

S 

An EMPLOYEE who is an active duty 
officer. 

AWARD 

1 

s 

An award or recognition that may be given 
to an EMPLOYEE as a reward for 
outstanding performance. 

BILLET 

1 

R 

A specific civilian or military job or 
position. 

BUDGET 

3 

R 

The financial spending plan of a command. 

COLLATERAL 

DUTY 

1 

R 

An duty assignment given to an 
EMPLOYEE in addition to their traditional 
duties. 

CONTRACT 

4 

R 

A legal document used to purchase goods oi 
services. 

CONTRACTOR 

1 

s 

A PERSON who is employed under a 
CONTRACT. 

COURSE 

1 

R 

A period of training. 

CUSTOMER 

3 

R 

Someone who receives service from the 
command. 





Entity Type Name 

HERD 

Section 

Entity 

Type 

Description 

DISTRIBUTION 

LIST 

4 

R 

A list of EMPLOYEES who receive a piece 
of INCOMING CORRESPONDENCE 
based upon its topic. 

EMPLOYEE 

1 

R 

A military or civil service PERSON who 
works for the ORGANIZATION. 

EVENT 

2 

R 

A meeting or briefing. 

EXPENDITURE 

3 

R 

An expense incurred by the 
ORGANIZATION. 

FACILITY 

2 

R 

A base, building or room under the 
management of the ORGANIZATION. 

FAMILY MEMBER 

1 

W 

A member of an EMPLOYEE’S family. 

GM 

1 

S 

A general management civil service 
EMPLOYEE. 

GS 

1 

S 

A general service civil service 

EMPLOYEE. 

INCOMING 

CORRESPONDENCE 

4 

R 

A piece of mail or message traffic received 
by the ORGANIZATION. 

INDIVIDUAL 

DEVELOPMENT 

PLAN 

1 

R 

A plan of short- and long-term goals for an 
EMPLOYEE. The plan usually contains a 
list of training COURSES that the 
EMPLOYEE will take during the next year. 

INVENTORY 

3 

R 

A group of items held in storage until 
ne^ed. 

LOG 

4 

R 

A list of events that transpired during a 
work shift. 
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Entity Type Name 

EERD 

Section 

Entity 

Type 

Description 

MAJOR PROPERTY 

2 

S 

Property that is classified by regulation as 
major. U? ally property that has a value 
greater than $5,000. 

MINOR PROPERTY 

2 

S 

Property that is classified by regulation and 
policy as minor. 

OFF-SITE 

CONTRACTOR 

1 

S 

A CONTRACTOR that does not work in 
the ORGANIZATION’S FACILITY. 

ON-SITE 

CONTRACTOR 

1 

S 

A CONTRACTOR that works inside the 
ORGANIZATION’S FACILITY. 

ORGANIZATION 

1 

R 

A Naval command, department or division. 

OTHER PROPERTY 

2 

S 

PROPERTY for which it is necessary to 
maintain its current location. 

OUTGOING 

CORRESPONDENCE 

4 

R 

Mail or message traffic that is originated by 
the ORGANIZATION. 

PERSON 

1 

R 

A person. 

PHONE CALL 

1 

R 

A phone conversation held by an 
EMPLOYEE. Usually longdistance calls. 

PLAN OF THE 

WEEK 

4 

R 

A weekly newsletter published by the 
ORGANIZATION. 

POA&M 

4 

R 

A plan of action to complete a goal. 

PRODUCT 

3 

R 

An item that is produced for a 

CUSTOMER. 

PROPERTY 

2 

R 

Equipment or items that are owned by the 
ORGANIZATION. 
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Entity Type Name 

HERD 

Section 

Entity 

Type 

Description 

QUALIFICATION 

I 

R 

A skill that is held by EMPLOYEES. 

REFERENCE 

4 

R 

An item that is used to hold information. 
Regulations, instructions and policies are all 
REFERENCES. 

SPECIAL 

PURCHASE 

3 

R 

An item that is not a federal government 
standard stock supply. 

STANDARD 

SUPPLY 

3 

R 

Items that are federal government standard 
stock supplies. 

SUPPLY LIST 

3 

R 

The federal government standard stock 
supply list. 

TRAVEL 

1 

R 

A business trip taken by an EMPLOYEE. 

TASK ORDER 

3 

R 

A work order issued against a 

CONTRACT. 

UNFUNDED 

REQUIREMENT 

3 

R 

An item or project the ORGANIZATION 
wishes to buy or complete that does not 
have funding in the BUDGET. 

VISITOR 

1 

S 

A PERSON who visits the 
ORGANIZATION. 

WG 

1 

S 

A wage grade civil service EMPLOYEE. 

WORK SCHEDULE 

1 

R 

A schedule of an EMPLOYEE’S working 
times. 

WORK REQUEST 

2 

R 

A request to repair a damaged FACILITY. 
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APPENDIX C 


THE PROTOTYPE 

This appendix contains the enhanced entity relationship model and one possible 
relational mapping of the prototype model developed for FLENUMOCEANCEN. 
The relational schema diagrammatic technique is that used by Kroenke and Dolan 
[Ref. 7:pp. 167-213]. A small number of attributes were chosen for the prototype: 

• ORGANIZATION; Organization Code, Organization Name, UIC, Message 
Address, Street, City, State, Zip 

• INCOMING CORRESPONDENCE: Serial Number, Originator, Standard 
Subject Identification Code, Subject, Date, Received Date 

• DISTRIBUTION LIST: Keyword, Organization Code 

• PLAN OF THE WEEK: Message, Start Message Date, Stop Message Date,. 
Message Priority 

• FACILITY; Facility Name, Facility Type 

• PROPERTY: Serial Number, Property Type, Cost, Nomenclature 

• PERSON: SSN, Last Name, First Name, Middle Name, Date of Birth 

• EMPLOYEE: Office Phone Number 

• VISITOR: Visit Start Date, Purpose of Visit, Visit Stop Date 

• ACTIVE OFFICER; Rank, Designator 

• GS: Series, Grade, Step 

• FAMILY MEMBER: First Name, Relationship 
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This EER diagram uses a different labeling convention to display the cardinality 
ratio discussed in Chapter III. The numbers in the parentheses represent the 
minimum and maximum participation of the entity ♦ype in the relationship type [Ref, 
l ;p. 57]. This convention provides more information than using the 1, N and M. 

For example, in Figure 9, an organization may manage zero (0) to many (N) 
facilities. Zero in the minimum number of facilities an o’^ganization may manage 
with no upper limit set on the maximum number of facilities an organization may 
manage (N). A facility must be managed by one and only one organization. 
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Figure 9. The Prototype HERD 
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Figure 10. The Prototype Relational Schema 
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